-
Notifications
You must be signed in to change notification settings - Fork 23
ref: generalize acceleration structures #990
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
1dad838 to
945980f
Compare
|
bfc4bde to
c4fc8a1
Compare
c4fc8a1 to
035a8e2
Compare
2c2a592 to
42588cc
Compare
ed1d019 to
ac50d9b
Compare
ac50d9b to
4659811
Compare
4659811 to
2b81f2b
Compare
|
main new Unfortunately, this seems to slow things down a bit and needs further investigation |
2b81f2b to
9a9b471
Compare
|
53f96cf to
36a3e26
Compare
36a3e26 to
7b1a04c
Compare
|
The latest benchmarks actually show no performance hit anymore: Unblocking |
|



Generalize the acceleration data structure implementation, so that also volume search data structures can be added in the future. In particular, the tracking volume and navigator can now call into surface and volume search data structures. The current surface accelerators are cleaned up and adapted to fulfill the new
acceleratorconcept.For this, the grid has been split into the 'utility' grid, which is also used by the material maps, and the spatial grid, which is now dedicated to spacial searches of contained surfaces or volumes. Both grid accelerator types (surface and volume) can now be added to the detector accelerator store. The spatial grid is equipped with a dedicated grid collection, which will make it easier in the future to add the mask data of the representing surface (this will need to be added to stay in sync with ACTS).
The actual volume accelerator data structures and their IO will be added in a future PR.